As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
When UEFI Secure Boot is enabled for a server, Basic Input/Output System (BIOS) and Unified Extensible Firmware Interface (UEFI) firmware perform authentication of component firmware, UEFI apps and operating system (OS) images. This authentication mechanism is time consuming as each of these images has to be signed using secure boot keys and also be verified by UEFI Secure boot algorithm. Such verification has adverse impacts on performance of boot process. In the past, these verification mechanisms have sometimes been skipped to enable a faster boot process for images/packages supplied by the server manufacturer itself. The decision making to bypass this verification is based on a pre-determined UEFI Hardware device path in the UEFI Core library of BIOS. However, this approach is not scalable when UEFI applications (apps) are hosted on devices that are created dynamically outside of the server BIOS. Examples of such devices include shared and network storage. The UEFI device path for such devices will vary and cannot be pre-determined. Further, such devices cannot be trusted and the authenticity of such applications is a security concern. Therefore, UEFI apps hosted on devices created dynamically outside of the server BIOS need a complete secure boot authentication which affects the server boot time.
FIG. 1 illustrates conventional UEFI secure boot methodology 100 that is performed by a processing device of a server to authenticate and load a UEFI component image such as device firmware image, UEFI application or OS Loader. Third party (e.g., vendor) UEFI components (e.g., such as UEFI driver or UEFI application) are conventionally loaded in this manner as shown in FIG. 1. In step 102 of FIG. 1, Driver Execution Environment (DXE) loader starts, and then in step 104 DXE loader accesses a secure input/output (IO) store (e.g., such as network storage or local universal serial bus device) to verify the device path of an image before beginning to retrieve and load the image, in this case a UEFI driver or UEFI application. Next, in step 106, DXE loader begins the loading process for the image from the IO store by checking to see if image code is signed by the OS manufacturer (e.g., such as Microsoft) to ensure authenticity. If the image is determined to be so signed in step 106, then loading of the image is completed by the DXE loader in step 107. However, if in step 106 it is determined in step 106 that the image is not signed, then the image is not loaded, but instead the image load fails in step 108. In the conventional methodology 100 of FIG. 1, all original equipment manufacturer (OEM)-supplied UEFI applications, OS loaders, server manufacturer firmware updates, OS driver packs, etc. all must be signed by an external party and stored in the server baseboard management controller (BMC). To successfully load a UEFI component image, a signed version of the UEFI component image must first be provided by the OS manufacturer or other external third party. This process is time consuming and adversely affects faster releases of third party (e.g., vendor) UEFI components, server manufacturer UEFI components, etc.